In a typical cellular network, also referred to as a wireless communication system, a wireless device, such as a User Equipment (UE), communicates via a Radio Access Network (RAN) to one or more Core Networks (CNs).
A wireless device is a device by which a subscriber may access services offered by an operator's network and services outside the operator's network to which the operator's radio access network and core network provide access, e.g. access to the Internet. The wireless device may be any device, mobile or stationary, enabled to communicate over a radio channel in the communications network, for instance but not limited to, e.g., mobile phones, smart phones, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, or any type of consumer electronic, for example but not limited to televisions, radios, lighting arrangements, tablet computers, laptops or Personal Computers (PCs). The wireless device may be portable, pocket storable, hand held, computer comprised, or vehicle mounted mobile devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another wireless device or a server.
Wireless devices are enabled to communicate wirelessly with the communications network. The communication may be performed, e.g., between two wireless devices, between a wireless device and a regular telephone and/or between the wireless device and a server via the radio access network, and possibly one or more core networks, and possibly the Internet.
The radio access network covers a geographical area which may be divided into cell areas, with each cell area being served by a base station, e.g. a Radio Base Station (RBS), which in some radio access networks is also called evolved node B (eNB), NodeB, B node or base station. A cell is a geographical area where radio coverage is provided by the base station at a base station site. The base stations communicate over the air interface with the wireless devices within range of the base stations. In the following, the term eNB may be used when referring to the base station, but the embodiments are not limited to the long term evolution (LTE) system and standards.
Multimedia Broadcast and Multicast Services (MBMS) is a broadcasting service offered via cellular networks. MBMS is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. MBMS may be used for file download and for streaming services, e.g., “Mobile TV”.
Enhanced MBMS (eMBMS) is an enhanced version of MBMS and it is used to denominate MBMS service in Evolved Packet Systems (EPS) including E-UTRAN (LTE) and UTRAN access. E-UTRAN is defined as Evolved UMTS Terrestrial Radio Access Network, UMTS is defined as Universal Mobile Telecommunications System, LTE refers to Long Term Evolution and UTRAN refers to Universal Terrestrial Radio Access Network. The eMBMS was included in the Third Generation Partnership Project (3GPP) release 9 specifications. The eMBMS is related to using LTE to simultaneously broadcast content to multiple wireless devices. An eMBMS may, for example, be particularly useful during live events, such as music concerts or sports events, where millions of consumers are simultaneously viewing the same content, and where eMBMS may be used to broadcast complementary content, like different camera angles for instance, to LTE wireless devices. eMBMS enables operators to make better use of their available spectrum and free up network capacity. Thus, the operators may maximize efficiency when offering services such as live TV, video on demand, podcasts, etc.
One aspect of eMBMS is MBMS single frequency network (MBSFN) transmission. A MBSFN area includes multiple cells in which transmission of identical waveforms is performed at the same time. A property of MBSFN transmission is that all participating cells transmit exactly the same content in a synchronized manner so it appears as one transmission to the wireless device. This makes it possible for wireless devices to combine MBMS transmissions from multiple cells. Transmitting the same data to multiple wireless devices allows network resources to be shared. Mechanisms are therefore provided to ensure synchronization of the MBMS content, i.e., to ensure that all participating base stations include the same MBMS control information and data in the corresponding time-synchronized subframe.
To achieve the MBSFN transmission, the following synchronizations are sought:                Network synchronization;        MBMS User Data flow synchronization; and        MBMS control plane synchronization (also called MCCH Update Signaling synchronization)        
MCCH refers to Multicast Control Channel and is a point-to-multipoint downlink channel used for transmitting MBMS control information from the base station to the wireless device. This channel is only used by wireless devices that receive MBMS.
The eMBMS is implemented in the third generation partnership project (3GPP) specifications by the addition of a number of new capabilities to existing functional entities of the 3GPP architecture and by addition of a new functional entity, a Multi-cell/multicast Coordination Entity (MCE). According to 3GPP, there are two eMBMS deployment alternatives:                Alternative 1: Standalone MCE, as shown in FIG. 1; and        Alternative 2: Distributed MCE, as shown in FIG. 2.        
FIG. 1 is an illustration of the eMBMS logical architecture of a communications network 10 with a standalone MCE 12 in communication with two base stations 14a and 14b, referred to collectively herein as base stations 14. The communications network 10 may include an LTE core network 10a and an LTE radio access network 10b. The Broadcast Multicast Service Center (BM-SC) 16 is an entity which controls MBMS sessions and corresponding MBMS bearers. As used herein the term “bearer” is used as is known in the art and generally refers to a set of network parameters that defines data-specific treatment, i.e., defines a virtual data pipeline, for a specified type of data, e.g., voice, video, etc. The dashed lines indicate a control plane interface whereas the solid lines indicate a data plane interface.
As noted, in FIG. 1, the MCE 12 is a logical standalone entity. The functions of the MCE 12 include admission control and allocation of radio resources used by all base stations 14, e.g., eNBs, in the MBSFN area. The standalone MCE 12 is involved in MBMS Session Control Signaling. The standalone MCE 12 decides when base stations 14 perform MCCH update signaling to wireless devices (not shown). Accordingly, MCCH update signaling synchronization may be achieved. Only two base stations 14 are shown in FIG. 1 for the sake of simplicity, but the skilled person will understand that more than two base stations 14 may be included in communications network 10.
The Mobility Management Entity (MME) 18 is a control node in the communications network 10. The MBMS Gateway (MBMS GW) 20, is an entity that is logically present between the BM-SC 16 and base stations 14. The functions of the MBMS GW 20 include sending/broadcasting of MBMS packets to each base station 14 transmitting the service. The MBMS GW 20 performs MBMS Session Control Signaling (Session start/stop) towards the E-UTRAN via the MME 12. The content provider 22 provides eMBMS services to the communications network 10.
In an LTE system, interfaces M1, M2 and M3 are present as follows. The M3 interface between the MCE 12 and the MME 18 is a control plane interface as indicated by the dashed line. The M1 interface is the interface between the MBMS GW 20 and the base stations 14, and is a user plane interface as indicated by the solid line. The M2 interface is a control plane interface between the MCE 12 and the base stations 14. The IP multicast on an M1 interface is used for point-to-multipoint delivery of user packets from the MBMS GW 20 to the base stations 14.
FIG. 2 is an illustration of an eMBMS logical architecture of a communications network 24 with a distributed MCE. The communications network 24 may include an LTE core network 24a and an LTE radio access network 24b. In FIG. 2, the base station and MCE are combined in a single entity 26. Two of these entities 26a and 26b are shown, although more than two may exist in an actual communications network. In FIG. 2, the M3 interface between the MCE 18 and the base station/MCE 26 is a control interface. The M1 interface between the MBMS GW 20 and the base station/MCE 26 is a user plane interface for point-to-multipoint delivery of user packets from the MBMS GW 20 to the base station/MCE 26.
Returning to FIG. 1, whenever the MCE 12 updates the control information, the MCE 12 indicates the modification period from which the updated control information applies by means of a parameter called MCCH update time. This concept is used in the distributed MCE architecture to synchronize control plane signaling. In particular, the MCCH update signaling for all base stations 14 is sent by sending the same MCCH update time to all base stations 14. Hence, the synchronization of the MCCH update signaling for all base stations 14 may be achieved. The range of the MCCH update time is 0-255, which is the number of MCCH modification periods elapsed since global positioning system (GPS) time 0, modulo 256.
The 3GPP standard supports control plane synchronization for the distributed MCE architecture of FIG. 2 by including the parameters “Time of MBMS Data Transfer” and “Time of MBMS Data Stop” in the MBMS session start request and the MBMS session stop request messages, respectively. The “Time of MBMS Data Transfer” and the “Time of MBMS Data Stop” are absolute timestamps which indicate the absolute time of the actual start or stop of the MBMS data transfer. Accordingly, all base stations/MCE 26 will transfer/stop user data at the same time.
Even though the 3GPP defines methods to synchronize sending of user plane data PDUs using M1 SYNC protocol and synchronize sending of MCCH control information using MCCH update time, possible muting, i.e., non-transmission of data, of ongoing services is inevitable during service addition or deletion. The MCE derives the MCCH update time and sends the MCCH update time to all base stations 14 as part of M2 scheduling messages. In present systems, the MBMS SESSION START REQUEST and the MBMS SESSION STOP REQUEST messages do not indicate when the M1 message is going to start or stop.
FIG. 3 is a timing diagram where muting occurs when starting a new MBMS service. Assume that a first service denoted as multicast traffic channel 1 (MTCH1) is ongoing when an operator wants to create a second service (MTCH2). The second service is going to be mapped to the same multicast channel (MCH) as the first service. The second service starts at a multicast control channel (MCCH) modification time period Y+1. The possible start time for the new service MTCH2 is anywhere during the MCCH modification time period Y+1. Two possible MTCH start times T1 and T2 during this modification time period are shown.
Regardless of when during the MCCH modification time period Y+1 the second service starts, the MCCH carrying the updated control information must be sent during the MCCH modification time period Y. When this occurs, the base station expects to send multicast scheduling information (MSI) at time x, (MSI(x)) with information for the second service. A Stop MTCH value for the second service is needed by the base station when building the information MSI(x). If synchronization packet data units (SYNC PDUs type 3) for the second service are not received by the base station in time for building the MSI(x), the base station will mute the ongoing services.
An explanation of a cause of this muting is as follows. The BM-SC is not aware of the base station MCCH boundaries and the second service may start at any time during MCCH modification time period Y+1. In order to minimize delay, sync PDU packets need to be received at the base station just before building a corresponding MSI(x). In this case, the first SYNC PDUs for MTCH 2 will arrive at multicast scheduling period (MSP) (x−1) for possible start time T1 and at MSP(x+2) for possible start time T2, where there are four MSPs for each MCCH modification time period in the example of FIG. 2. Thus, for possible start time T2, the base station will not receive any SYNC PDUs for the second service when building MSI(x). In this case, the base station does not know whether the base station did not receive the SYNCH PDUs corresponding to MTCH2 due to transport network failure, delayed packet arrival or other valid reason for muting, or due to not receiving data for MTCH2 because the service has not started yet. Accordingly, the base station mutes the MCH during the MSPs (x), (x+1) and (x+2) of the MCCH modification time period (Y+1), when the start time for MTCH2 is at time T2. This muting causes an unsatisfactory user experience, since service on the MCH is detectably interrupted.
FIG. 4 is a timing diagram where muting occurs when stopping an ongoing MBMS. Assume that two services, MTCH1 and MTCH2, are ongoing simultaneously, and the operator wants to stop the second service, MTCH2. The second service is going to be stopped during MCCH modification time period (Y). The possible stop time for the second MTCH2 could be closer to the MCCH modification period start boundary (T3) or could be closer to the end boundary (T4). Regardless of the stop time, the second service MTCH2 can only be removed from the MCCH at MCCH modification time period (Y+1). Thus, the MCCH update for MTCH2 is sent during the MCCH modification time period (Y+1). In this case, the base station expects to send multicast scheduling information MSI(x), MSI(x+1), MSI(x+2) and MSI(x+3) with information about MTCH2. The stop MTCH value for the second service must be known when building these MSIs. If the SYNC PDUs corresponding to the second service are not received by the base station before building the MSIs, the base station mutes the ongoing services of the MCH, even though all of the SYNC PDUs for the first service are received in time.
The BM-SC does not know when the MCCH boundaries of the base station occur and the service MTCH2 can stop at any time during the first MCCH modification time period (Y). When the second service MTCH2 is stopped, the BM-SC will not send any corresponding SYNC PDUs. So, for possible stop time T3, the base station will not receive any SYNC PDUs when building the MSIs. The base station does not know whether the lack of receipt of the SYNC PDUs is due to transport network failure or other valid reason for muting, or because the service has stopped. As a consequence, the MCH is muted during the MSPs in MCCH modification time period (Y) starting with MSI(x+1), when the stop time for the MTCH2 is at time T3. This muting causes an unsatisfactory user experience, since service on the MCH is detectably interrupted.